CURRENT_MEETING_REPORT_ Reported by Dave O'Leary/SURAnet UCP Minutes We started by discussing the issue of funding for the activity that is being proposed in the draft RFC. We decided that the focus of the group should be only on the definition of the inter-NOC protocol and to handle issues of multi-NOC coordination, with the goal being the tracking of complaints rather than tracking problems. Tracking of complaints provides accountability information for the funding agencies. We then read through the current version of the RFC, section by section, and discussed needed changes: NSC's: The issue of NOC certification needs to be clarified, and a mechanism for maintaining the ``phonebook'' of NSC's must be decided upon, although these tasks are outside the scope of this document. It is clear that certification and an entry in the phonebook are a one-to-one correspondence. Clear job descriptions for NSC's, the ``phone book registrar'', etc., are needed, but again, should not be part of this document. Holes in the phonebook are a problem. We cannot set enforcement policies for implementation of the ideas proposed in this document, but with an incomplete phonebook there may be situations where a ticket is opened but the entity responsible for fixing the problem is not a registered NSC and does not/cannot accept the ticket. Because of these potential holes in the book, particular organizations are very exposed in the initial system, as they receive many calls, and are forced to open tickets for each complaint, however there may be no means for them to resolve the problem or to pass it off to the responsible entity. An 800 number NSC Referral service should exist, i.e., ``I have this problem, who do I call?'' - somebody to look in the phonebook for those users that don't have a copy. Those listed in the phonebook must get a copy of the phone book. The User Services Working Group Ombudsman may be able to serve in this role. We discussed the possibility of ``You aren't our customer'' answers to 1 user calls. The RFC explicitly disallows this, and it was noted that this restriction could be relaxed in the presence of a national user ombudsman. Next we discussed the idea of ``entitlement'' - is every user promised ideal service? We concluded that every user has a right to be made aware of and expect the level of service he is willing to subscribe to. It was noted that there are some fundamental problems from expectations of those people who are not actually directly paying for any service, i.e., a graduate student at a large university doesn't have too much say as to the university network connection purchasing decisions. It was decided that an NSC can refer a user to another ticket and refer the user to the resolution of that ticket, i.e., clustering of several user complaints under one actual set of ticket transactions. We then discussed mechanisms for sharing internal ticket information between NOCs. Use of a common archiving mail list and the Internet Rover were proposed as two possible solutions. Vikas, Dale Johnson, Tim Salo, Tom Easterday, Dan Long and Dave O'Leary volunteered to start work on this via a mailing list. Ticket Processing It was decided that a NOC could refer a user after it had transferred responsibility for a ticket, i.e., ``We don't have information about that ticket anymore, please call Other NSC at 555-1234''. We discussed problems with unregistered NSC's, particularly complaints that are caused by software vendor's bugs. We discussed our role as an enforcement agent with software vendors, i.e., tracking the number of vendor X problems that are currently holding open tickets in the system. Ticket Support Centers We decided that although the three functions are essentially autonomous, they will probably reside within the same entity, although they do not have to. Dialogs Multiple User dialogs can map into one Operations dialog, and multiple Operations dialogs can map into one Engineering dialog. Meta dialogs can be associated anywhere into the hierarchy. The goal of the system is closure with the user, not closure of operational problems. It was noted that ``dead'' tickets could exist, where nobody really cares about 2 the resolution, and that a mechanism for tracking chronic problems is important. Explicit closure with the user is required, unless the user waives the right to this explicit closure. Individual NOC ticket design is not within the scope of the group, and it was recognized that significant post-processing of tickets will have to occur in many cases. We started to look at individual problems and how a typical ticket would be tracked through this system. It was decided that it is okay to tell the user the status of engineering problems. We discussed the case of unreasonable user demands - those who are never satisfied and those who generate many repetitive queries. The problems that we are trying to solve with the system: 1. Complaints that are dropped between NOCs. 2. NOCs that ``lose'' tickets - i.e., quality control on other NOCs. - expected level of service is an issue here. 3. Communication on complaints for knowledge of operational and engineering situations. 4. Statistics on complaints. 5. Accountability A different agenda is being addressed by each of the four dialogs, so the ticketing system must address these four issues. Individual tickets may not have discussion in each of the four dialogs. The introduction to the dialog section should preclude the possibility of separation of dialogs, i.e., each discussion should be taken in the context in which it was generated. Regarding the final status of tickets, it was re-emphasized that tickets are closed in the User dialog. Engineering problems are resolved by the responsible NSC, possibly at a different time from the closure with the user. Tickets can be closed with unhappy users, i.e., if an engineering problem exists with no solution in the foreseeable future. A question is how to measure the relative satisfaction before and after the problem. Access to Tickets An NSC can access any ticket in which it is referenced. Unregistered entities (i.e., other NOCs) can also access tickets in which they are 3 referenced. It may be appropriate to provide the user more data than is formally required. Ticket Tracking System It Holds: o Ticket Numbers o Ticket Status (for each dialog) o Parties Involved with Ticket o A Recent Copy of the Ticket (much discussion was generated) Privacy Issues: o What do the funding agencies think about this? o What about disinterested parties with complaints from users? o What about the persons involved? At the end, Matt volunteered to work on the introduction to the document to clarify the focus in two ways: 1. It is specifically addressing user complaints. 2. It is addressing inter-NOC problem resolution. Following the group meetings, a document editing session was held with Matt Mathis, Dan Long, Gene Hastings, and Dave O'Leary. A new draft will be available soon and inserted into the informational internet-drafts track. Attendees Vikas Aggarwal vikas@JVNC.net Ronald Broersma ron@nosc.mil Robert Collet /pn=robert.d.collet/o=us.sprint/admd=telemail/c=us/@sprint.com Tom Easterday tom@nisca.ircc.ohio-state.edu Jeff Forys forys@cs.utah.edu Vince Fuller vaf@Standford.EDU Jack Hahn hahn@umd5.umd.edu Eugene Hastings hastings@psc.edu Dale Johnson dsj@merit.edu 4 Dan Jordt danj@cac.washington.edu Darren Kinley kinley@crim.ca Walter Lazear lazear@gateway.mitre.org Daniel Long long@bbn.com Matt Mathis mathis@pele.psc.edu Judy Messing messing@gateway.mitre.org Donald Morris morris@ucar.edu David O'Leary oleary@noc.sura.net Mark Oros oros@nmc.cit.cornell.edu Timothy Salo tjs@msc.edu Tom Sandoski tom@concert.net Kannan Varadhan kannan@oar.net 5